FIG. 1 shows a network computer 10 running, inter alia, Java enabled browser software 11. The software 11 communicates with web servers across the Internet to download information using HTTP (hypertext transfer protocol). More and more frequently, users are conducting commercial transactions across the Internet. In FIG. 1, a user running the software 11 needs to conduct transactions via the Internet through, for example, an IBM CICS (trademark of IBM) transaction processing system. A CICS system comprises a server 12, and a plurality of client workstations 14, only one shown. The client workstation runs CICS client software 16 for communicating with the server 12 across a link using EPI (External Presentation Interface) or ECI (External Call Interface) requests and replies. It is also possible for a CICS client workstation 14 to act as a Web server, using appropriate software 18 supporting HTTP. This allows one or more network computers to connect to the workstation 14 across the Internet to download information defining, for example, front screen displays for inputting and receiving transaction information, as well as indictors for any Java programs (applets).
The need to interface between Java programs running in a remote location, for example, the Internet Web browser 11, to existing or new applications running in a second location, for example a transaction processing system 12/16, results in the need for a Java Gateway 20 to bridge between the two locations.
This Gateway could be, and normally is, specifically designed to support the particular semantics of the second location application with hard coded messages and message specific code in the Gateway.
However, such a solution is inflexible since it is not easy to expand the supported interfaces/applications without having to rebuild and update the Gateway to understand them. Also it results in each application in the second location having its own Gateway implementation, rather than all applications using a single Gateway.